1. Field of the Invention
The present invention relates generally to an automated transaction system and in particular to a workflow management system and data collection system for a transaction based system.
2. Description of the Related Art
Processing commercial transactions is a complicated process involving organizations as customers, institutional-wide policies and numerous tasks that must be completed by various departments within banks, hospitals, warehouses, manufacturing facilities or other industrial, commercial, financial, health care or government institutions. Such tasks include inventory control, pharmaceuticals, commercial loans, verifying data, evaluating risks and approving and administering transaction based decisions.
These tasks are generally performed by multiple computer applications performing specific functions in the life-cycle of the transaction. For example, documentation systems prepare documents, accounting systems manage payments, collateral tracking systems follow collateral and compliance systems prepare governmentally required reports.
Business processes are often characterized by the need to have different people or departments perform work on various pieces of the same business data at different points in the process. Each individual person or department has different responsibilities for the transaction and therefore may need access to different aspects of the transaction. Current systems allow a user to search the transaction using different criteria, including customer number, social security number, transaction id, including combinations thereof. These searches are usually performed at the start of a process and each time the user returns to the system. It would be beneficial to have a system which filtered the transactions based upon the user's responsibilities upon access to the system.
One method currently used to address this issue is to allow the user to define a specialized view of a set of data and build a custom report based on that data. For example, a user might want to find all transactions with a value over $1 million dollars because the user must approve those transactions. Current transaction systems may be able to provide that information. However, the user simply wanted to know what transactions needed his approval, current systems would have difficulty providing that type of information. In another example a clerk may be able to prepare loan documents based upon loan transaction information; however, the document preparation system does not instruct the clerk which loan transactions need to have documents prepared. The current method does not allow the user to select a subset of data relevant to the user. It would be beneficial to create a system which integrated the user and institutional information and instructed the user which transactions needed to be processed, allowing the user to perform the actual task that is within his area of responsibility.
In addition, it would be helpful to add a functional menuing system with relevant or desired functional features. This would allow the users to perform functional tasks from their display screens. It would also be of further benefit to allow the user to quickly and automatically navigate to a specific data field within the transaction-based system through an auto-navigation feature.
As described above, the institutional transaction process being a transaction-based system involves a number of different systems and individuals performing a specific task on the transaction at any given time. Because of the diversity of systems used in the institutional process, a user must educate himself on using the various systems as well as where within each system a specific item may be located. With the complexity of these systems, it is often difficult to remember specifically where an item is within the system, and the user is required to spend non-productive time trying to locate the item. It would be beneficial to create a single point of entry for a user to organize the various resources he interacts with and simplify the job of executing each task that routinely arises. In addition, it would be helpful if the single point of entry was customizable to each individual user allowing him to see the items which may be of most importance to him.
As previously mentioned, some financial institutions have applications specifically designed for individual aspects of the lending process, with a fixed, hard-coded menuing system. In addition to the confusing, inconsistent graphical interfaces between the different systems, when a new screen or function is added additional programming is required to modify menus and system navigation logic. The result is a confusing user interface for users to operate and a system with higher maintenance costs because of its inflexibility. It would be beneficial to have an integrated, interactive graphical user interface which provides a predictable screen structure, imposing parent-child screen relationships, auto and manual navigational elements, security and functional features which are utilized consistently throughout the transaction.
During the life cycle of a institutional transaction, a transaction requires interaction from a number of different individuals and various departments throughout the institution, each with their own level of authority, responsibilities and access to data to coordinate the necessary approvals and numerous documents involved in the process. As the transaction travels through the institutional process system, it moves from department to department and then back again. In this way work may be assigned to a supervisor based upon geographic factors, or to a team member based upon department organization. Furthermore, each employee must have valid authorization to review and/or perform his job specific functions on the transaction. It would be beneficial to represent the institution's organizational hierarchy within a transaction-based system in order to control access to application data and application functions as well as work assignments and additional system related features.
As described above, transaction process system in use today are comprised of various software systems which have a variety of computerized applications, each designed to handle certain specific functions during the end-to-end transaction cycle of the transaction. In the course of the life cycle of the transaction, the transaction suffers from inefficient processing of the transaction because there are many changes in the transaction which are untracked and/or undocumented. Most changes are documented on single purpose manual logs which are not integrated throughout the departments or provided to the employees responsible for the transaction. At a given point in time, it is difficult to determine which steps have been completed and which are outstanding as the transaction progresses through its life-cycle. The status is therefore difficult to determine at any given point in time. Because of the uncertainty in determining the transaction's status, there is a general lack of accountability for the transaction and there is a risk that some critical tasks remain unperformed or that transaction processors may be unaware of needed action. It would be beneficial to display the current status of the monitored functions, provide a place for assignment of the loan transaction to various users, provide a place to record specific and general information regarding the current condition of the transaction and to maintain a history log of the transaction's activities throughout its life-cycle.
In addition, to the numerous users and systems currently in place in typical commercial institutions, the authority is also segregated. This authority is typical charged with approving the transaction and any amendments thereto. In current transaction systems, this approval is complicated, time consuming, highly susceptible to human error and can be disruptive to processing workflow and transaction closing deadlines. Within a commercial lending institution for instance, lending authority is divided among lenders, senior lenders, other types of senior managers and loan committees. The ways in which lending limits are distributed among these roles vary greatly; however, they follow similar patterns. For example, a junior lender might not have any lending authority and may be required to consult with a mentoring lender for any approval decisions. The lender then might have basic authority to loan up to a certain limit i.e. $100,000 versus $10,000,000) or he may be limited based upon the type of loan (i.e. secured versus unsecured) or the terms of the loan (i.e. 12 months versus 60 months). A senior lender, market manager or committee member might have higher authority with certain key managers having higher authority, and the loan committee having authority for the remaining loans. During processing of the loan, the approval is verified to make sure that the proper approval has been obtained for the loan and any amendments thereto with phone calls, manual signatures or other manual steps. This tracking is time consuming, subjective and highly dependent on well-trained and knowledgeable loan servicing staff. Further, because financial institutions are often spread-out over various distances in different officers, senior lenders and managers may be located in different facilities and the loan documents may be missing one of the required signatures. In addition, if the loan was committee approved, either meeting minutes must be obtained with proper signatures or the signature of every committee member may be required. This method is time consuming, subject to error and can be disruptive to meeting the turnaround times required for loan processing.
Other approval concerns in institutional systems are to insure that the approval matches the institution's, institution-wide policies along with a means for the tracking and auditing of transaction statistics. It would be beneficial to have an approval process in a institutional transaction system in which information was provided about the type of approval needed for the transaction along with a place to approve and/or record or signify approval of the transaction and any amendment to it as well as some indication that the data was accurate and certified.
For example, commercial financial institutions establish polices which govern the terms of loans which will be accepted and the standard practices which will be adhered to. In the course of negotiating the loan, deviations to the standard policies or loan terms will be requested. Some examples include a request for customized loan language or changes of specific loan terms, or the borrower may have had a negative history with the institution, or be within a highly volatile industry with questionable longevity. These conditions or deviations may necessitate a review of the loan or the proposed loan by the lender's legal department. In addition, certain loan factors may require a legal department review. Existing systems typically rely upon manual human intervention to identify a loan for legal review. In addition, existing systems often provide no effective means to track and ensure that the institution's legal review policies are followed. Failure to follow proper legal review can result in drastic consequences, including an inability to collect on the loan or a loss of rights to take the collateral which was pledged against repayment of the loan. It would be beneficial to have a commercial lending system which provides a place to communicate a request for legal review, provides facilities for the reviewer to approve or decline loan changes, records and logs such approval or rejection and provides the ability to generate an automated request for legal review based upon specific criteria.
In addition to the complexities surrounding an institution, the customer and collateral involve unique complexities. Commercial customers are often organizations with multiple entities within the organization, each entity having unique characteristics. These entities often have ongoing relationships with the institutions, acquiring multiple transactions which are being paid at any given time. The collateral which is used to secure a commercial loan also has complex qualities. In a commercial loan, a single collateral item can be used simultaneously on multiple loans. In some cases an older loan may close out before earlier loans using the same collateral. Because both customers and collateral may be repeated throughout the commercial lending process, it would be beneficial to allow the loan data to reused in such a way that the unique identification of the data can be customized for a specific loan transaction while preventing the corruption of the data itself.
Prior art attempts to addresses problems included Norris U.S. Pat. No. 6,105,007, which discloses an automatic financial account processing system which uses a kiosk to conduct loan transactions. Davidson, U.S. Pat. No. 5,699,527 discloses a method and system for processing a loan by having a loan applicant input loan data and then transmit the data to a lending institution. However, heretofore there has not been available a commercial loan transaction system with the advantages and features of the present invention.